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October 1, 1999 
Assistant Commissioner for Patents 
BOX PATENT APPLICATION 
Washington, DC 20231 

PRELIMINARY AMENDMENT 

Dear Sir: 

This is a preliminary amendment to a continuation of U.S. Patent Application 
Serial No. 08/987,346, filed December 9, 1997, and is filed with the request for the 
continuation application. Please amend the continuation patent application as 
follows before its consideration: 



In the title 

Please replace the title with a new title: 

- Method and Apparatus for Accessing a Common Database from a Mobile 
Device and a Computing Device -- 



In the specification 



Please insert on page 1, between "File No.: 89710-2" and " REFERENCE TO 
MICROFICHE APPENDIX", the following paragraph: 

-The present application is a continuation of pending application No. 
08/987,346, filed on 12/09/97, entitled "Method And Architecture For Self- 
Provisioning a Rendezvous To Ensure Secure Access to Information In a Database 
From Multiple Devices", now allowed. - 

In the claims 

Please cancel claims 1-31 without prejudice. 

Please add the following new claims (numbered 32-104): 

32. A method for accessing data contained in a data network system, comprising: 

sending a request to a server hosting the data to retrieve the data by 
activating a key of a mobile device, the request being sent by executing a first set of 
program instructions in the mobile device, wherein the mobile device has a display 
screen and is in communication, over a wireless data network with the server, and 
further, wherein the data is associated with the mobile device and is also accessible 
by a computing device executing a second set of program instructions and coupled 
to the server through a data network; 

receiving the data from the server via the wireless data network, the data 
presented in a first format interpretable by the first set of program instructions; and 

displaying the data on the display screen of the mobile device. 

33. The method of claim 32, wherein the data is presented in a second format when 
accessed by the computing device. 

34. The method of claim 32, wherein the first format is a first markup language 
for use with a mobile wireless device operating in the wireless data network. 
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35. The method of claim 34, wherein the first markup language is Handheld Device 
Markup Language (HDML). 

36. The method of claim 33, wherein the second format is a second markup 
language for use with a computing device operating in the data network. 

37. The method of claim 36, wherein the second markup language is Hypertext 
Markup Language (HTML). 

38. The method of claim 33, wherein the first format is used to display the data on 
the mobile device and the second format is used to display the data on the 
computing device. 

39. The method of claim 32, wherein the first set of program instructions is included 
in a first browser program operated in the mobile device. 

40. The method of claim 32, wherein the data comprises at least one of (i) an 
address book entry, (ii) a bookmark to a web site, and (iii) a link to a source of 
information, and is accessible from the computing device executing the second set 
of program instructions. 

41 . The method of claim 32, wherein the data comprises data for configuring or re- 
configuring a feature of the mobile device. 

42. The method of claim 32, wherein the mobile device is a wireless telephone. 

43. The method of claim 32, wherein the mobile device includes a processor, and 
further, wherein the processor controls a telephony function. 

44. The method of claim 32, wherein the data comprises a plurality of selectable 



hyperlinks, with each of the hyperlinks providing access to a resource in the data 
network, and further, wherein the displaying comprises displaying at least one of the 
selectable hyperlinks on the display screen of the mobile device using the first set of 
program instructions. 

45. The method of claim 44, further comprising: 

sending a second request from the mobile device to the server by executing 
the first set of program instructions, the second request acting to fetch information 
associated with one of the hyperlinks. 

46. The method of claim 32, wherein the request comprises an address identifier 
identifying the server. 

47. The method of claim 46, wherein the address identifier is a universal resource 
locator (URL). 

48. The method of claim 32, wherein the sending a request further comprises: 

determining whether a communication session between the mobile device 
and the server is in existence or is valid, wherein the determining of the 
communication session further comprises: 

creating the communication session between the mobile device and 
the server if the communication session is not in existence or is not valid; 

conducting mutual authentication between the mobile device and the 
server; and 

generating session credential information for the communication 
session, wherein a subsequent communication between the mobile device 
and the server is encrypted by the session credential information; and 
forwarding the session credential information to the server to access the data 
if the communication session is in existence or is valid. 
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49. A method for accessing data contained in a data network system, comprising: 

receiving a request from a mobile device through a wireless data network to 
access the data, the data being associated with an account for the mobile device 
and the mobile device having a display screen, wherein the data is accessible by a 
computing device remotely located and coupled to a data network selected from a 
group consisting of the Internet, a private network and a network of public and 
private networks; 

retrieving the data after the request is authenticated with respect to the 
account; and 

forwarding the data to the mobile device in a first format displayable on the 
display screen of the mobile device. 

50. The method of claim 49, further comprising: 
prompting the computing device for credential information when the 

computing device attempts to access the data; and 

providing access to the data in a second format after the credential 
information is verified. 

51. The method of claim 50, further comprising: 

updating the data upon receiving updated information from the computing 
device. 

52. The method of claim 49, wherein the first format is used to display the data on 
the mobile device and the second format is used to display the data on the 
computing device. 

53. The method of claim 52, wherein the first format is a first markup language and 
the second format is a second markup language. 



54. The method of claim 49, wherein the data comprises a plurality of hyperlinks, 
and further, wherein the retrieving further comprises: 

contacting a resource identified by the one of the hyperlinks over the data 
network; 

fetching the data in a second format from the resource; and 
converting the fetched data to the first format. 

55. The method of claim 54, wherein the first format is a first markup and the second 
format is a second markup language. 

56. The method of claim 49, wherein the data comprises data for configuring or re- 
configuring a feature of the mobile device. 

57. The method of claim 49, wherein the mobile device is a wireless telephone. 

58. The method of claim 49, wherein the mobile device includes a processor, and 
further, wherein the processor controls a telephony function. 

59. The method of claim 49, wherein the request includes an update to the data and 
causes the data to be updated. 

60. A wireless mobile device for accessing data in a data network system, 
comprising: 

a display screen; 

a memory containing program code for a first browser program; and 

a processor, coupled to the display screen and the memory, and capable of 

executing the program code to enable the first browser to perform the operations 

of 

sending a request over a wireless data network to a server hosting the 
data to retrieve the data after activation of a key of the mobile device, 
the data being associated with the mobile device and accessible by a 



computing device executing a second browser and coupled to the 
server through a data network; 
receiving the data from the server via the wireless data network, the data 

presented in a first format interpretable by the first browser; and 
displaying the data on the display screen of the mobile device. 

61. The device of claim 60, wherein the data is presented in a second format when 
accessed by the computing device. 

62. The device of claim 60, wherein the first format is a first markup language. 

63. The device of claim 62, wherein the first markup language is Handheld Device 
Markup Language (HDML). 

64. The device of claim 61, wherein the second format is a second markup 
language. 

65. The device of claim 64, wherein the second markup language is Hypertext 
Markup Language (HTML). 

66. The device of claim 61 , wherein the first format is used to display the data on the 
mobile device and the second format is used to display the data on the 
computing device. 

67. The device of claim 60, wherein the data comprises at least one of (i) an 
address book entry, (ii) a bookmark to a web site, and (iii) a link to a source of 
information, and is accessible from the computing device executing the second set 
of program instructions. 

68. The device of claim 60, wherein the data comprises a plurality of selectable 
hyperlinks, with each of the hyperlinks providing access to a resource in the data 



network, and further, wherein the displaying comprises displaying at least one of 
the selectable hyperlinks on the display screen of the mobile device. 

69. The device of claim 68, wherein the first browser further performs the operations 
of: 

sending a second request from the mobile device to the server by executing 
the program code, the second request acting to fetch information associated with 
one of the hyperlinks. 

70. The device of claim 60, wherein the request comprises an address identifier 
identifying the server. 

71. The device of claim 70, wherein the address identifier is a universal resource 
locator (URL). 

72. The device of claim 60, wherein the sending a request further comprises: 

determining whether a communication session between the mobile device 
and the server is in existence or is valid, wherein the determining of the 
communication session further comprises: 

creating the communication session between the mobile device and 
the server if the communication session is not in existence or is not valid; 

conducting mutual authentication between the mobile device and the 
server; and 

generating session credential information for the communication 
session, wherein a subsequent communication between the mobile device 
and the server is encrypted by the session credential information; and 
forwarding user credential information to the server to access the data if the 
communication session is in existence or is valid. 

73. The device of claim 60, wherein the data comprises data for configuring or re- 
configuring a feature of the device. 



74. The device of claim 60, wherein the device is a wireless telephone. 

75. The device of claim 60,wherein the processor of the device also controls a 
telephony function. 

76. An apparatus for accessing data contained in a data network system, 
comprising: 

a memory containing program code for a server module; 

a processor, coupled to the memory, and capable of executing the program 
code to enable the server module to perform the operations of 

hosting the data, the data associated with an account for a mobile device, the 
device having a display screen, and the data being accessible by a 
computing device remotely located and coupled to a data network 
selected from a group consisting of the Internet, a private network and a 
network of private and public networks; 

receiving a request from the mobile device through a wireless data network to 
access the data; 

retrieving the data after the request is authenticated with respect to the 
account; and 

forwarding the data to the mobile device in a first format displayable on the 
display screen of the mobile device. 

77. The apparatus of claim 76, wherein the processor further enables the server 
module to perform the operations of 

prompting the computing device for credential information when the 

computing device accesses the data; 
providing access to the data in a second format after the credential 

information is verified; and 

updating the data upon receiving updated information from the computing 
device. 



78. The apparatus of claim 76, wherein the data is presented to the computing 
device in a second format, and further, wherein the first format is a first markup 
language and the second format is a second markup language. 

79. The apparatus of claim 78, wherein the first format is used to display the data on 
the mobile device and the second format is used to display the data on the 
computing device. 

80. The apparatus of claim 76, wherein the data comprises a plurality of hyperlinks, 
and further, wherein the retrieving further comprises: 

contacting a resource identified by the one of the hyperlinks over the data 
network; 

fetching the data in a second format from the resource; and 
converting the fetched data to the first format. 

81. The apparatus of claim 76, wherein the data comprises data for configuring or 
re-configuring a feature of the mobile device. 

82. The apparatus of claim 76, wherein the mobile device is a wireless telephone. 

83. The apparatus of claim 76, wherein the mobile device includes a processor, and 
further, wherein the processor controls a telephony function. 

84. A computer readable medium encoded with computer program code executable 
in a mobile device having a display screen, for accessing data contained in a 
data network system, comprising: 

program code for sending a request over a wireless data network to a server 
hosting the data, the data being associated with the mobile device and 
accessible by a computing device coupled to the server through a data 
network; 
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program code for receiving the data from the server via the wireless data 
network, the data received presented in a first format displayable by the 
mobile device and presented in a second format when accessed by the 
computing device; and 
program code for displaying the data on the display screen of the mobile 
device. 

85. The computer readable medium of claim 84, wherein the first format is a first 
markup language. 

86. The computer readable medium of claim 85, wherein the first markup language 
is Handheld Device Markup Language (HDML). 

87. The computer readable medium of claim 84 wherein the second format is a 
second markup language. 

88. The computer readable medium of claim 87, wherein the second markup 
language is Hypertext Markup Language (HTML). 

89. The computer readable medium of claim 84, wherein the first format is used to 
display the data on the mobile device and the second format is used to display 
the data on the computing device. 

90. The computer readable medium of claim 84, wherein the data comprises at least 
one of (i) an address book entry, (ii) a bookmark to a web site, and (iii) a link to a 
source of information. 

91. The computer readable medium of claim 84, wherein the data comprises a 
plurality of selectable hyperlinks, with each of the hyperlinks providing access to 
a resource in the data network, and further, wherein the displaying comprises 



displaying at least one of the selectable hyperlinks on the display screen of the 
mobile device. 

92. The computer readable medium of claim 91, further comprising program code 
for sending a second request from the mobile device to the server to fetch 
information associated with one of the hyperlinks. 

93. The computer readable medium of claim 84, wherein the request comprises an 
address identifier identifying the server. 

94. The computer readable medium of claim 93, wherein the address identifier is a 
universal resource locator (URL). 

95. The computer readable medium of claim 84, wherein the program code for 
sending a request further comprises 

program code for determining whether a communication session between the 
mobile device and the server exists or is valid, wherein the program code 
for determining a communication session further comprises 

program code for creating the communication session between the 
mobile device and the server if the communication session is not in 
existence or is not valid; 
program code for conducting mutual authentication between the mobile 
device and the server; and 

program code for generating session credential information for the 
communication session, wherein a subsequent communication 
between the mobile device and server is encrypted by the session 
credential information; and 
forwarding the credential information to the server to access the data if the 
communication session is in existence or is valid. 



96. The computer readable medium of claim 84, wherein the data comprises data 
for configuring or re-configuring a feature of the mobile device. 

97. The computer readable medium of claim 84, wherein the mobile device is a 
wireless telephone. 

98. The computer readable medium of claim 84, wherein the mobile device includes 
a processor, and further, wherein the processor controls a telephony function. 

99. A computer readable medium encoded with computer program code executable 
in a server hosting data, the data accessible by a mobile device executing a first 
browser and by a computing device executing a second browser, wherein the 
mobile device is coupled to the server through a wireless network and the 
computing device is coupled to the server through a data network, comprising: 

program code for receiving a request from the mobile device through the 

wireless network to access the data; 
program code for retrieving the data; 

program code for forwarding the data to the mobile device in a first format 
displayable on the display screen of the mobile device. 

1 00. The computer readable medium of claim 99, further comprising: 
program code for prompting the computing device for credential information 

when the computing device attempts to access the data; 
program code for providing access to the data in a second format after the 

credential information is verified; and 
program code for updating the data upon receiving updated information from 
the computing device. 

101. The computer readable medium of claim 1 00, wherein the first format is used 
to display the data on the mobile device and the second format is used to display 
the data on the computing device. 
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1 02. The computer readable medium of claim 99, wherein the data comprises data 
for configuring or re-configuring a feature of the mobile device. 

1 03. The computer readable medium of claim 99, wherein the mobile device is a 
wireless telephone. 

1 04. The computer readable medium of claim 99, wherein the mobile device 
includes a processor, and further, wherein the processor controls a telephony 
function. 

Remarks 

This is a preliminary amendment filed with an accompanying request for a 
continuation application to U.S. Patent Application Serial No. 08/987,346. 
Applicants respectfully request the Examiner to enter the above amendments before 
considering the patent application. 

The amendment to the title is intended to make it more consistent with the 
new claims, and that to the specification is for the purpose of reciting the relationship 
with the pending application. Pending claims 1-31 are canceled by virtue of the 
preliminary amendment, and new claims 32-104 are added. The new claims find 
support in the specification and no new matter has been added by the amendments. 



The applicant believes $1 ,948.00 is the only fee to be due in this amendment. 
The Commissioner is authorized to charge this fee and any fees beyond this amount 
which the PTO believes may be required, or to credit any overpayment, to Deposit 
Account No. 50-0516. 

Please telephone the undersigned at (650) 817-1610, if there are any 
questions, or if a conference with the Examiner would assist in the examination of 
this case. 
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REFERENCE TO APPENDIXES ' 

Appendix A, which is a part of the present disclosure, is a microfiche appendix 
consisting of 2 sheets of microfiche having a total of 195 frames. The microfiche Appendix is 
a source code listing of one embodiment of the authentication and provisioning process in the 
present invention, which is described more completely below. 

A portion of the disclosure of this patent document contains material, that includes, 
but is not limited to, Appendix A and Appendix B, which is subject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction by anyone of the patent 
document or the patent disclosure, as it appears in the Patent and Trademark Office patent file 
or records, but otherwise reserves all copyrights whatsoever. 

BACKGROUND OF THE INVENTION 
Field of Invention 

u 

The invention relates to user authentication systems over data network systems, and 
more particularly relates to a method and system for self-provisioning, through a first device, 
a rendezvous to ensure secure access to managed information in a user account by other 
devices through the rendezvous in a data network, wherein the rendezvous is generally 
identified by a URL, the first device, coupled to the data network, runs a first browser under a 
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first communication protocol and the other devices in the same data network run a second 
browser under a second communication protocol. 

Description of the Related Art 

The Internet is a rapidly growing communication network of interconnected 
5 computers around the world. Together, these millions of connected computers form a vast 
repository of hyperlinked information that is readily accessible by any of the connected 
computers from anywhere and anytime. To provide mobility and portability of the Internet, 
wireless computing devices were introduced and capable of communicating, via wireless data 
networks, with the computers on the Internet. With the wireless data networks, people, as they 
10 travel or move about, are able to perform, through the wireless computing devices, exactly the 
same tasks they could do with computers on the Internet. 

The most common remote access paradigm is, as of today, the one in which a laptop 
personal computer is equipped with a wireless communication mechanism, for example, a 
wireless modem. This paradigm may remain useful for a considerable number of applications 

15 and users, but there has been a growing need for a mobile paradigm in which the Internet can 
be instantly accessed by mobile devices, such as cellular phones and personal digital 
assistants. The mobile devices are generally designed small in size and light in weight. With 
increasing data processing capabilities in the mobile devices, more and more users start 
carrying the devices around to materialize their unproductive time into productive time. As 

20 more commonly seen, regular mobile phones can return calls, check voice mail or make users 
thereof available for teleconferences anywhere and anytime, but desired mobile phones, not 
just reactive to calls but also proactive, can meld voice, data, and personal information 
manager-like functionality into a single handset that can effectively, through a host computer, 
access a myriad of public and enterprise information services in the Internet. 
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The evolution of the mobile phones or the mobile devices has been fueled by the 
demand of users for immediate access to the information they are looking for. For example, a 
traveler may request an exact flight schedule when he is on his way to airport, or a trader may 
purchase shares of stock at a certain price. The pertinent information from these ideas or 
transactions may include the airline and the flight number for the traveler as well as the 
number of shares and the price thereof being purchased by the trader. To be timely informed, 
a preferable way is to communicate the information requests electronically into the wireless 
data network. The data network, for example, connects to a flight information server or stock 
quote server so that the desired flight information or the current stock price can be retrieved 
therefrom on demand. However, it becomes troublesome or impractical to key in lengthy 
information queries electronically into the data network through a mobile device that typically 
has a keypad with a few buttons, much less functional compared to a keyboard in a personal 
computer system. There is therefore a great need for a method and system for efficiently 
communicating desired transactions into a data network through which the transactions can be 
performed or pertinent information can be retrieved without the need to key in such every 
time the transactions or the information are desired. In many cases the desired information in 
a user account, especially regarding personal matters, is preferred to be confidential. Thus 
there is further a need for a generic solution that provides a method and means for self- 
provisioning an account entry to a user account that has the proprietary information therein 
accessible only through the account entry. 

SUMMARY OF THE INVENTION 

The present invention has been made in consideration of the above described problems 
and has particular applications to systems of self-authentication by authorized users using 
devices that have limited computing power. Cellular phones are the typical example that has 
very little computing power and memory to satisfy the power long lasting and portability 
requirement, others include Internet-enabled electronic appliances that generally have 



computing powers at a minimum as to reduce the cost thereof for market popularity. All these 
devices, considered as thin devices or clients herein, in data networks, provide users with 
portable, convenient, and instant access to information being sought in the Internet; for 
example, retrieving a list of stock quotes using a mobile phone or viewing a list of interested 
5 news stations on Internet-connected TVs. In both examples, the mobile phone and a remote 
control of the TV have very limited user interface to receive inputs from users. One of the 
important aspects of the present invention is to provide a generic solution for communicating 
desired ideas or transactions from other devices with rich user interface to such a thin client 
through a self-provisioned account entry. 

10 While administrated user authentication systems over data networks have been used 

extensively in areas such as administered network computers and electronic commerce in the 
Internet, the present invention disclosing a method and system for self-provisioning, through a 
first device, e.g. the cellular phone or the remote control, a rendezvous to ensure secure access 
to a user account by other devices through the rendezvous yields unexpected results. The 

15 administrated user authentication systems in computer networks generally require each 
account holder to remember his username and associated password. If the username and 
password were ever lost or forgot, the corresponding account becomes abandoned or must be 
clarified by a system administer. The disclosed invention, however, allows a user to self- 
provision an account entry or a rendezvous with a set of credential information, which does 

20 not require the user to write down or remember the credential information in order to access 
his account. Further, the user is the only one who knows the credential information created in 
an authenticated and secure communication session for the rendezvous, thereby the account 
becomes truly proprietary. Moreover through the rendezvous, the present invention for the 
first time allows efficient means for communicating personalized information into a database 

25 by utilizing other computers running an HTML browser with more familiar graphic user 
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interface while allowing a thin device running a micro browser to access the same 
personalized information stored in the database. 

According to one preferred embodiment of the present invention, a method for 
provisioning, through a thin device, a rendezvous to a user account in a server to ensure 
5 secure access to the user account by a networked computing device through the rendezvous 
having a URL, thereby the networked computing device can update managed information in 
the user account that is also accessible by the thin device, the method comprises: 

initiating a transaction signal by the thin device to the server; the thin device having a 
client identification associated with the user account in the server and running a micro 
10 browser supported by a first communication protocol, wherein the transaction signal 
comprises the client identification and the URL of the rendezvous; 

examining a communication session between the thin device and the server, wherein 
the session examination between the thin device and the server comprising: 

creating the communication session between the thin device and the server if the 
15 communication session is not in existence or is not valid; 

conducting mutual authentication between the thin device and the server; and 

generating session credential information for the session such that subsequent 
transactions between the thin device and the server are encrypted by the session credential 
information; and 

20 establishing user credential information for the rendezvous by the thin device; and 

associating the user credential information with the rendezvous to the user account in 
the server. 

Upon updating the user credential information to the rendezvous, the networked 
computing device with the correct user credential information can go through the rendezvous 
25 to the user account to edit, modify or update the managed information, e.g. a URL of a Web 
server, in the user account with a much convenient information entering means, such as an 
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HTML browser. The thin device can immediately access the managed information, such as 
the specified URL, to retrieve pertinent information therefrom without the need to key in the 
URL that often has a number of alphabets. 

The system for secure access to a user account in a server, through a rendezvous 
5 identified generally by a URL, the rendezvous being exclusively designated to the user 
account, the system comprising: 

a data network comprising an airnet supporting a first communication protocol and a 
landnet supporting a second communication protocol, the landnet coupled to the server; 

a first client device, remotely located with respect to the server device and coupled to 
10 the airnet using a first communication protocol, having a client identification exclusively 
associated with the rendezvous and running a first browser ; 

a second client device coupled to the landnet using a second communication protocol 
and running a second browser; 

means for mapping the first communication protocol to the second communication 
15 protocol and the second communication protocol to the first communication protocol; the first 
client communicating with the server via the communication protocol means; 

means for mapping the first communication protocol to the second communication 
protocol and the second communication protocol to the first communication protocol; 

means for creating an authenticated and secure communication session between the 
20 first client device and the server through the data network; the session creating means 
comprising: 

means for requesting the session by the first client device to the server if the 
session is not in existence or is not valid; 

means for conducting mutual authentication between the first client device and the 
25 server; and 

means for generating session credential information for the session in creation; and 
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means, by the first client and through the created session, for updating the rendezvous 
with user credential information by a first browser such that the user account is accessible by 
the second client through the rendezvous with the user credential information. 

Accordingly, an important object of the present invention is to provide a generic 
solution for self-provisioning a rendezvous to a corresponding user account created and 
authorized in a server; 

Another object of the present invention is to provide a method and system for efficient 
and secure access to a user account by self-provisioning a rendezvous to the account as such 
any computer with a much convenient information entering means may update managed 
information in the account; and 

Other objects, together with the forgoing are attained in the exercise of the invention 
in the following description and resulting in the embodiment illustrated in the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features, aspects, and advantages of the present invention will become 
better understood with regard to the following description, appended claims, and 
accompanying drawings where: 

Figure 1 shows a schematic representation of a data network in which the present 
invention may be practiced; 

Figure 2.a and 2.b illustrates a representation of system architecture of the present 
invention and a layout of a corresponding user account in a server in communication with a 
mobile phone and a PC; 

Figure 3 shows a typical example of a mobile device that houses one potion of the 
linked and complied processes disclosed in the present invention; 
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Figure 4 illustrates a schematic representation of a mutual authentication process 
between a mobile device and a host server to ensure subsequent information transacted 
therebetween is secured; 

Figure 5. a and 5.b demonstrate a flowchart showing the corresponding processes in 
5 each of the involved devices, respectively; and 

Figures 6, 7, 8, 9 and 10 illustrate, respectively, examples of personalizing a user 
account being accessed through a self-provisioned rendezvous. 

DETAILED DESCRIPTION OF THE INVENTION 

In the following detailed description of the present invention, numerous specific 
10 details are set forth in order to provide a through understanding of the present invention. 
However, it will become obvious to those skilled in the art that the present invention may be 
practiced without these specific details. In other instances, well known methods, procedures, 
components, and circuitry have not been described in detail to avoid unnecessarily obscuring 
aspects of the present invention. 

15 The detailed description of the present invention in the following are presented largely 

in terms of procedures, steps, logic blocks, processing, and other symbolic representations 
that resemble the operations of data processing devices coupled to networks. These process 
descriptions and representations are the means used by those experienced or skilled in the art 
to most effectively convey the substance of their work to others skilled in the art. The present 

20 invention is a method and system for self-provisioning a rendezvous through a thin device to 
ensure secure access by other devices to information in a database in a data network. The 
method along with the system or architecture to be described in detail below is a self- 
consistent sequence of steps leading to a desired result. These steps or processes are those 
requiring physical manipulations of physical quantities. Usually, though not necessarily, these 

25 quantities may take the form of electrical signals capable of being stored, transferred, 
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combined, compared, displayed and otherwise manipulated in a computer system or electronic 
computing systems. It proves convenient at times, principally for reasons of common usage, 
to refer to these signals as bits, values, elements, symbols, operations, messages, terms, 
numbers, or the like. It should be borne in mind that all of these similar terms are to be 
5 associated with the appropriate physical quantities and are merely convenient labels applied to 
these quantities. Unless specifically stated otherwise as apparent from the following 
description, it is appreciated that throughout the present invention, discussions utilizing terms 
such as "processing" or "computing" or "verifying" or "displaying" or the like, refer to the 
actions and processes of a computing system that manipulates and transforms data represented 
10 as physical quantities within the computing device's registers and memories into other data 
similarly represented as physical quantities within the computing device or other such as 
storage, transmission or display devices, 

Referring now to the drawings, in which like numerals refer to like parts throughout 
the several views. Figure 1 shows a schematic representation of a data network 100 in which 

15 the present invention may be practiced. The data network 100 comprises an airnet 102 that is 
generally called wireless network and a landnet 104 that is generally a landline network, each 
acting as a communication medium for data transmission therethrough. The airnet 102, in 
which transmission is via the air, is sometimes referred to as a carrier network because each 
airnet is controlled and operated by a carrier, for example AT&T and GTE, each having its 

20 own communication scheme, such as CDPD, CDMA, GSM and TDMA for the airnet 102. 
The landnet 104 or the Internet, used interchangeably herein, may be the Internet, the Intranet 
or other private networks. Referenced by 106 is a mobile data device, but resembling a mobile 
phone therein, in communication with the airnet 102 via an antenna 108. It is generally 
understood that the airnet 102 communicates simultaneously with a plurality of mobile 

25 computing devices of which only a mobile or cellular phone 106 is shown in the figure. 
Similarly, connected to the Internet 104 are a plurality of desktop PCs 110 and a plurality of 
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servers 1 12, though only one representative respectively shown in the figure. The PC 110, as 
shown in the figure, may be a personal computer SPL 300 from NEC Technologies Inc. and 
runs a HTML Web browser via the Internet 104 using HTTP to access information stored in 
the web server 1 12 that may be a workstation from SUN Microsystems Inc.. It is understood 
5 to those skilled in the art that the PC 110 can store accessible information therein so as to 
become a web server as well. Between the Internet 104 and the airnet 102 there is a link 
server 114 performing data communication between the Internet 104 and the airnet 102. The 
link server 1 14, also referred to as link proxy or gateway, may be a workstation or a personal 
computer and performs mapping or translation functions, for example, communication 
10 protocol mapping from one protocol to another, thereby a mobile device 106 can be in 
communication with any one of the servers 1 12 or the PCs 110, respectively. 

The communication protocol in the Internet 104 is the well known HyperText Transfer 
Protocol or HTTP and runs on TCP and controls the connection of a well known HyperText 
Markup Language Web browser, or HTML Web browser, to a Web server and the exchange 

15 of information therebetween. The communication protocol between the mobile device 106 
and the link server 1 14 via the airnet 102 is Handheld Device Transport Protocol (HDTP), or 
Secure Uplink Gateway Protocol (SUGP), which preferably runs on User Datagram Protocol 
(UDP) and controls the connection of a HDML Web browser to a link server, where HDML 
stands for Handheld Device Markup Language, it is similar to that of HTML and a set of 

20 commands or statements that specify how information displayed. The specifications of both 
HDTP and HDML, being considered as the wireless network standards, are provided at 
http://www.w3.org or http://www.uplanet.com and incorporated herein by reference. Further a 
reference specification entitled "Magellan SUGP Protocol", a HTTP specification with 
network security features is incorporated herein by reference as Appendix B. The HDTP is a 

25 session-level protocol that resembles the HTTP but without incurring the overhead thereof 
and is highly optimized for use in mobile devices that have significantly less computing 
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power and memory. Further it is understood to those skilled in the art that the UDP does not 
require a connection to be established between a client and a server before information can be 
exchanged, which eliminates the need of exchanging a large number of packets during a 
session creation between a client and a server. Exchanging a very small number of packets 
5 during a transaction is one of the desired features for a mobile device with very limited 
computing power and memory to effectively interact with a landline device. 

Referring now to Figure 2, there is depicted a representation of the architecture 120 of 
the present invention. As described above, the airnet 102 communicates simultaneously with a 
plurality of two-way mobile communication devices, 122, 124 and 126, generally from a 

10 group consisting of mobile phones, two-way pagers and telephones, such as a Duette cellular 
phone from Samsung Telecommunication America, Inc.. Due to the increasing reduction in 
size and weight and high portability, most of the mobile devices, considered as thin clients, 
have a very limited computing power, typically equivalent to less than one percent of what is 
provided in a typical desktop or portable computer, the memory capacity in a thin client is 

15 generally less than 250 kilobytes and the LCD display thereof is perhaps four lines high by 
twelve or twenty characters, the graphics capabilities thereof are very limited or nearly 
nonexistent and the general user interface is a keypad having far less buttons than a PC 
keyboard does. Therefore many transactions desired by users through such clients are 
preferably predetermined or pre-entered in their user accounts in a host server 128 as such the 

20 users need only to select desired transactions to perform or at most key in one or two letters 
corresponding to desired entries through the keypads of their cellular phones. For example, if 
there is a list of stock symbols of interest in a user account that is designated to a mobile 
phone, a user of the mobile phone will not have to key in the symbols every time he desires to 
look up for the price thereof currently being traded in the stock market. The list of stock 

25 symbols is previously entered to the user account. Evidently the most available and 
convenient means for now is to use a computing device that has powerful and full functional 
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information entering capabilities. A PC is a typical example of such computing device, the PC 
can be equipped with the well-known HTML browser that provides a rich graphic user 
interface and an ideal environment for the user to manage his personalized information in his 
account. 

5 As is well known, the Internet 104 is typically a network of networks connecting 

computers that are provided the HTML browser. Referenced by 1 10 is a PC representing one 
of the computers that use the HTML browser running on HTTP to hyperlink to other 
computers/servers 132 or 134 to update/fetch information on line or simply copy files 
therefrom. It should be noted that "user account" and "database" have been used herein 

10 sometimes interchangeably when only one account is being addressed. It is generally 
understood that a database or an allocation of memory, as referenced by 130 in the figure, 
hosts a plurality of user accounts, each designated to an authorized capacity in which 
managed or personalized information is kept. Further it is understood that the database 130 
can be an independent storage or physically a part of the host server 128. To access the 

15 personalized information therein from any computer on the Internet 104, one has to provide 
an account entry, namely a rendezvous, to a user account in the host server 128 or database 
130 with a set of credential information such as a username and a password thereof. Figure 
2.b illustrates a layout of a typical user account assigned with a mobile phone 106. Each 
mobile phone is assigned to a device ID 140 which can be a phone number of the phone or a 

20 combination of an IP address and a port number, for example: 204.163.165.132:01905 where 
204.163.165.132 is the IP address and 01905 is the port number. The device ID 140 is further 
associated with a subscriber number (sub #) 142 authorized by a carrier in the link server 1 14 
as part of the procedures to activate the phone 106. The sub # may take the form, for example, 
of 861234567-10900_pn.mobile.att.net by AT&T Wireless Service, it is a unique 

25 identification to the phone 106. In other words, each of the mobile devices 122, 124 and 126 
has a unique device ID that corresponds to a user account in a server, respectively. It may be 
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appreciated by those skilled in the art that the link server 1 14 does not have to be a separate 
sever to perform the communication protocol mapping, it can be just a part of the host server 
128 and the protocol mapping is a part of functions the host server 128 provides. 

A corresponding account 144 in the database 130 is indexed by an account structure 
5 143 comprising the sub # 142, user information 146, a username 148 and a password 150. The 
sub # 142 is received from the link server 114 as an index to the account structure 143, the 
user information 146 comprises the account configuration and other account related 
information. The username 148 and the password 150, namely the user credential information, 
control the authentication to enter the account 144 in the database 130. From the data network 

10 perspective, any computer can logon through HTTP to the rendezvous 152 identified by an 
address identifier, often a universal resource locator (URL) taking the form of www.xyz.com. 
In other words, each account in a database is exclusively associated with a rendezvous 
identified by a unique URL. As shown in the figure, the PC 1 10 establishes a communication 
session with the rendezvous 152 based on a given URL of the rendezvous 152. However, to 

15 access the associated account 144 in the database 130, the PC 110 must provide a set of 
correct username and password to the rendezvous 152 that performs a verification thereof 
with the account structure 143. If the supplied username and password match those in the 
account structure 143, the access requested by the PC 1 10 is allowed. Otherwise, the entry to 
the account 144 is denied. 

20 The PC 110 can update information stored in the account 144 when the supplied 

username and password are verified. Using the powerful and familiar HTML browser in the 
PC 1 10, a user can key in frequently request information, such as a list of stock symbols and a 
list of URLs of Web servers that provide services to the phone 106. An example will be 
provided later. All the information entered through the PC 1 10 become immediately available 

25 to the phone 106. 
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A process named webpwd.cpp in the code listing in the appended Microfiche 
Appendix A illustrates a provisioning process between the phone 106 and the link server 1 14 
in one embodiment of the present invention. Upon the request of the phone 106, the process, 
specifically in a subprocess called setNameAndPasswordState(), allows the phone 106 to 

5 supply a username and a password and then send the newly supplied credential information to 
a second subprocess called submitState() that checks if the entered username and password 
are acceptable, namely the username and password should have a certain length and contain 
no spaces or unrecognized characters with respect to a general rule of being a username and 
password. If the username and password are not acceptable, the subprocess submitState() 

10 returns to the phone 106 with a corresponding message being either "You must enter a name" 
or "You must enter a password". Otherwise, the newly entered username and password are 
sent to another subprocess called SetUserAuth() in a process called HTTPDBMSUserDB. The 
subprocess SetUserAuth() updates the username and password in the account structure 143, 
which immediately requires all subsequent logins to the account entry 152 with the newly 

15 supplied username and password. A subprocess Authenticate() examines a set of username 
and password supplied by the PC 106, it compares the username and password from the PC 
110 to the ones in the account structure 143. It the comparison is successful, the subprocess 
Authenticate() returns a AuthPass flag that allows the PC 110 to access the account in the 
database. Otherwise, it returns a flag that denies the admission of the PC 100 to the account. 

20 It should be noted that the communication between the phone 1 06 and the link sever 

1 14 is through the airnet 102 in Figure L Message carrying proprietary information travelling 
in the air is not secure. To transact credential information over the open space to provision the 
rendezvous, user must have an efficient, reliable and secured manner to conduct private 
communications with the link server. According to one embodiment of the present invention, 

25 an authenticated and secure session between the cellular phone 106 and the link server 114 
must be in place before the cellular phone, or through which the user, provisions the 
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rendezvous to access his account from other computers. It is necessary to refer to an 
architecture of a mobile phone before proceeding with the detail description of creating the 
authenticated and secure communication between a user's phone (client) and a server. Figure 
3 is shown a block diagram of a typical GSM digital cellular phone 160. Each of the hardware 
components in the cellular phone 160 is known to those skilled in the art and so the hardware 
components are not to be described in detail herein. Although the user interface of the phone 
160 is not shown in detail in the figure, the mobile device 118, resembling a cellular phone, in 
Figure 1 may be referenced thereto, in which referenced by 1 16 is a LCD screen and 1 18 is a 
key button pad, respectively. The screen 1 16 prompts user what to proceed with the keypad 
118, with a sequence of key entries and through the phone 160, a user can interactively 
communicate with a server through the airnet, link server and the Internet. According to one 
embodiment of the present invention, complied and linked processes of the present invention 
are stored in ROM 162 as a client module 164 and support module 166. Upon activation of a 
predetermined key sequence utilizing the keypad 118, a physical layer processor or 
microcontroller 118, initiates a session communication to the server using the module 164 in 
the ROM 162. 

To establish a secured communication between a cellular phone (a client) and a server, 
an authentication process must be conducted first to ensure that only interested parties are 
actually in the communication therebetween. According to one embodiment of the present 
invention, the code listing thereof being provided in the appended Microfiche Appendix, the 
process is complete through two rounds of independent authentication, one being the client 
authenticated by the server, referred to as client authentication, and the other being the server 
authenticated by the client, referred to as server authentication. Further each authentication is 
completed in two separate steps for high grade of security, which will be described in detail 
below. The success of the mutual authentication processes provisions an evidence that the two 
communicating parties possesses a valid shared secret encrypt key through a mutual 
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decryption and a challenge/response mechanism. The mutual decryption mechanism 
comprises the steps of mutually recovering encrypted messages from two involved 
communicating parties. The challenge/response mechanism, referred to as nonce verification, 
verifies a predetermined relationship between a sent nonce and a received derivative thereof. 

5 In one preferred embodiment of the present invention, the authentication process is 

conducted with three message exchanges; a Session Request (SR), a Session rePly (SP), and a 
Session Completion (SC). Figure 4 illustrates a schematic representation of the authentication 
process. The client 170, representing a mobile device or the cellular phone 106 of Figure 1, to 
conduct a transaction with the server 172, representing a link server 1 14 of Figure 2, initiates 

10 a SR 174 to be sent to the server 172 by first creating a client proto-session. A client proto- 
session is a session data structure that gets initialized when a session creation starts. The 
initialized SR 174 comprises the following essential information: 

sessionID - an identifier identifying all requests from the client to the server; In the 

case of requesting a session creation, sessionID is always assigned to 0; 

15 cipher - a two-byte number representing the choice of the encryption the client is 

currently using as there are a number of encryption schemes available in a 
communication protocol; 

devicelD - a variable up to 255-byte, representing the device identifier or the client 
identifier comprising, a phone number of the device or an IP address and a port 
20 number, e.g. 204.163.165.132:01905 ; and 

C-nonce - a client nonce represented with a non-repeatable number, usually 2 bytes, 
used for the client to conduct a following server authentication. 

C-nonceModified - a modified version of the client nonce, used for the server to 
conduct a nonce verification in the following client authentication. 
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Further the cipher in the SR 174 includes an identifier to an encryption algorithm and 
associated parameters thereof. To be more specific, the first byte in the cipher represents an 
identifier to a combination of the encryption algorithm, the key size (e.g. 128-bit for US or 
40-bit for foreign countries) and content of a security attachment thereto and the second byte 
5 in the cipher indicates the additional parameters related to the first byte.JFor example, value 1 
in the first byte indicates that the encryption algorithm is block cipher RC5, the key size 
thereof is 128 bit, a two byte check-sum therein is used as the MAC (Message Authentication 
Code), no IV (Initialization Vector for block ciphers) therefor is transmitted over the network, 
and padding bytes are added if necessary. The block cipher algorithm RC5 is part of the 
10 RSA's BSAFE product. It can be further appreciated that the identifier in the cipher may be 
assigned to a unique value to identify a non-secure session if so desired. The C-nonce is a 
non-repeatable number initially and randomly generated in the client and the modified version 
thereof, C-nonceModified, is generated from the C-nonce through a operational relationship; 
for example the Exclusive-OR relationship or expressed as follows: 

15 C-nonceModified = 2-byte-number © C-nonce. 

It can be appreciated by those who are skilled in the art that there are many ways to get the C- 
nonceModified from a C-nonce, the Exclusive-OR is one of the operational relationships used 
in one embodiment of the present invention. Both C-nonce and C-nonceModified are 
encrypted using the shared secret encrypt key between the client 170 and the server 172. The 
20 purpose of the C-nonceModified is to provide the server that receives the SR with means for 
ensuring that C-nonce is correctly decrypted and validated by examining the C-nonce and its 
relationship with the C-nonceModified. Both should not be altered after a successful 
decryption of the C-nonce and the C-nonceModified. In other words, a SR message or signal 
may be expressed as follows: 

25 SR = {session ID, cipher, device ID, Encry [nonce, nonceModified]}; 
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where Encry[ ] means that the parameters or contents in the bracket are encrypted 
accordingly. When the SR is sent by the client to the server to request a session creation, both 
C-nonce, C-nonceModified are encrypted according to the cipher the client is using at the 
time the SR is sent out. 

5 Upon receiving the SR from the client 170, the server 172 creates a server proto 

session for the client 170 with a session identifier, referred to as session ID, to identify the 
session context for the session just created in the server 172. A server proto-session is a 
session entry marked as a proto status in a session table, which indicates that the session is not 
authenticated and is not able to conduct any transactions with the client. It is understood to 

10 those skilled in the art that the proto-session can be kept in the RAM of the server. If a proto- 
session already exists for that client, it is re-used. The information in the received SR is saved 
in the server proto-session. If the server 172 is satisfied with the fact that the client is known, 
namely Encry[C-nonce, C-nonceModified] in the received SR are successfully decrypted with 
the shared secret encrypt key, the step one in the client authentication is successful and a 

1 5 corresponding session key is generated and stored with the server proto session entry. It may 
be noted herein that many encryption schemes used in this invention, such as the scheme 
utilizing RC5, have a procedure that adds and validates the Message Authentication Code 
such as the check-sum, to assure that the encrypted message is correctly decrypted, the 
procedure, every time the decryption takes place, is used herein to examine the transaction 

20 integrity, namely to assure the received messages or signals are unaltered in the cause of data 
transmission. If the step one client authentication is not successful, namely Encry [C-nonce, C- 
nonceModified] in the received SR are not fully decrypted or supported, the proto session is 
aborted and removed from the proto session table, resulting in a failed session creation. What 
the support means herein is the cipher proposed or used by the client is also used by the 

25 server, for example the client uses the RC5 encryption to encrypt Encry[C-nonce, C- 
nonceModified], to decrypt Encry [C-nonce, C-nonceModified], the server must be equipped 
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with the same RC5 encryption capability therein. If Encry[C-nonce, C-nonceModified] can 
not be successfully decrypted due to other reasons such as transmission errors, the client must 
reinitiate a new session request to the server in order to establish a secure communication with 
the server. To challenge the step two server authentication subsequently at the client side, a 
5 derivative of the client nonce or C-nonce, is generated therefor. In one embodiment of the 
present invention, the derivative is created by adding a constant to the client nonce, for 
example derivative = C-nonce + L The purpose of the derivative is to provide the client with 
means for reassuring that the C-nonce is correctly decrypted by the server and the server is the 
right one in communication with. 

10 Right after the successful step one client authentication, the server 172 responds to the 

client with a Session rePly (SP) 176 to begin a second round authentication; server 
authentication. The SP 176 comprises the following information: 

C-SID - a one byte number indicates the sessionID originally assigned in the client, to 

be more specific C-SID = 0 indicates a clear text client session, C-SID = 1 indicates a 
15 shared secret key encrypted session, and C-SID = 2 indicates a session key encrypted 

session. In the context of the current description, C-SID = 1. 

sessionID - a four-byte number representing an identification and parameters, such as 
a session encrypt key, of the session created by the server for the client; 

key - a session key to be used with a mutually acceptable encryption, and to be used 
20 for encryption and decryption in all transactions in the session; 

derivative - a number derived from the C-nonce for the client to perform the 
subsequent server authentication; 
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S-nonce - a non-repeatable number, used for the server to conduct a following step- 
two client authentication; it should be noted that S-nonce is generated by the server 
and generally different from the C-nonce by the client; and 

cipher - a two-byte number representing the choice of the encryption the server 
5 proposes after the client proposed cipher is received, it may or may not be the same as 

the one used in the client, to be more specific, the cipher is the same as the one 
proposed by the client when the server supports the client proposed cipher, otherwise 
the cipher is the one currently used in the server. 

In other words, the SP can be expressed as follows: 

10 SP={C-SID, Encry[sessionID, key, S-nonce, derivative, cipher]}; 

When the client 170 receives the SP 176 from the server 172, it performs the step one server 
authentication, which is considered successful if EncryfsessionID, key, S-nonce, derivative, 
cipher] in the received SP 176 is decrypted successfully with the shared encrypt key. If the 
step one server authentication fails, the client 170 discards the SP 176 and a new session 
15 creation may be started over again. Upon the success of the step one server authentication, the 
client 170 proceeds with the step two server authentication; namely the predetermined 
relationship between the C-nonce and the derivative thereof should be hold for a successful 
step-two server authentication: 

C-nonce = derivative -1 

20 If the C-nonce derived from the SP 176 is the same as the C-nonce originally 

generated by the client, the step two server authentication is successful, hence the server 172 
is considered authenticated, trusted from the viewpoint of the client, and the SP 176 is 
accepted as a valid message, which means that the client 170 then uses the session key and 
other information in the SP 176 for the session being created. Only with both successful steps 
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of the server authentication, the client 170 marks the session as committed, which means that 
transactions can be conducted subsequently in the session, again only from the viewpoint of 
the client 170, If the predetermined relationship between the client nonce and the derivative 
thereof does not hold, the step two server authentication fails and the received SP 176 is 
5 discarded. The client 170 may abort the session creation process if no further SP's are 
received and pass both steps of the server authentication during the time period allowed for a 
session creation. To provide the server with means for reassuring the client authentication by 
itself through the client, a derivative of the S-nonce, similar to the derivative of the C-nonce, 
is generated. 

10 The client 170 then sends the server 172 a SC 178 to complete the session creation 

process. The SC 178 comprises the following information: 

SO{Encry [derivative] } ; 

where the derivative is the client's response to the server nonce challenge, namely the result 
of the verification, the derivative is used by the server 172 for step two client authentication. 
15 Further it is noted that the SC 178 is an encrypted message, meaning that the client encrypts 
the information in the SC 178 according to either its own cipher or the server proposed cipher. 
Generally the client 170 encrypts the information in the SC 178 according to the server 
proposed cipher if it accepts the server proposed cipher, otherwise, it encrypts the SC 
according to its own cipher. 

20 Upon receiving of Session Complete or SC 178, the server 172 tests if the client 170 

uses its own proposed cipher or the server proposed cipher by decrypting the SC twice using 
the two ciphers if necessary. If the server 172 decrypts the encrypted message in the SC 178 
and verifies the relationship thereof with the S-nonce^ the step two client authentication is 
succeeded. Subsequently the server 172 promotes the server proto session to the active 

25 session and the session creation process is completed, thereby an authenticated and secure 
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communication session is established between the client and the server. Any transactions in 
the established communications session are now encrypted by the session key created in the 
server according to a cipher mutually agreed by both the client and the server, thereby the 
transactions between the client and the server are truly proprietary. A code listing of one 
embodiment of the mutual authentication is listed in the Appendix A. 

Referring now to Figure 5.a and 5.b, each is illustrated a flowchart showing the 
processes of the present invention in each involved device, respectively, in conjunction with 
Figures 6, 7, 8, 9 and 10 demonstrating examples of personalizing a user account being 
accessed through a self-provisioned rendezvous. A client 200, which can be a cellular phone, 
in Figure 5.a is one of the mobile devices communicating with a server 250 in Figure 5.b 
through a data network that is not shown in these figures but illustrated in Figure 1 or Figure 
2. It should be noted that the server 250 functions as a link server and a host server. The 
functional flowcharts on the client and server sides are conjointly described in the following 
with respect to a cellular phone. Nevertheless it will be appreciated by those skilled in the art 
that a server, without reciting specifically a link server or a host server, as referenced by 250 
can perform similar functions, this becomes evident when the client is a landline device 
having direct communication to the Internet. 

As part of the procedures to activate a cellular phone, a user account, or sometimes 
called device account, is created in the server 250, the account is exclusively associated with 
the phone or client 200. In other words, each mobile device in the data network has its own 
account identified by a corresponding device ID and subsequently a sub # in the server 250. 
The account for the client 200 is therefore created and configured at 252 according to services 
subscribed by the client 200. Meanwhile a corresponding account structure, similar to 143 in 
Figure 2b, is initiated at 254. With an established account in the server 250, the client 200 
becomes one of the clients capable of communicating with any computers in a data network. 
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When a user desires to update his personalized information in his account, he needs to 
first self-provision the rendezvous associated with his account using the client 200. The phone 
therefore requests a communication session to the server 250 at 202 for subsequent 
transactions to take place in an authenticated and secure communication session. From the 
5 session creation described above, it can be appreciated that the session creation requested by 
the client 200 includes a piece of device information assigned to the client 200. If, at 204 and 
206, the device information sent to the host is not recognized by the contacting host 250, no 
communication session can be possibly established therefor. Meanwhile the host 250 receives 
the session request from the client 200, as part of the session creation process, the device 

10 information is examined at 260 and the session creation process proceeds when the device 
information is verified at 262, that means that the device 200 has an authorized account 
therein. At 208 and 264 respectively, a mutual authentication process between the client 200 
and server 250 takes place. As described above, the mutual authentication process comprises a 
client authentication and a server authentication, each further comprising two respective steps 

15 to ensure that the communicating party is authenticated. Resulting from the mutual 
authentication process or once the session is created and authenticated at 210 and 266 of the 
client 200 and the serve 250, respectively, a set of session credential information is generated. 
The session credential information comprises a session ID, a session key and a session cipher. 
The session ID is used to distinguish the session from other sessions that the host is creating 

20 or has already established with other mobile devices or clients, and the session key and the 
session cipher are to encrypt transactions between the client 200 and the server 250. At 212, 
the client 200 is acknowledged that there is a rendezvous associated with the account 
designated to the phone 250. If the user desires to update his personalized information in the 
account created and authorized in the server 250, he may proceed at 214 with the rendezvous 

25 that is generally identified by a URL provided by the host 250 and is subsequently prompted 
for a set of user credential information, such as a username and a password. At 216, the user 
credential information is entered. The credential information is then sent to the host 250 at 
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218, which includes a process of ensuring the newly supplied username and password satisfy 
a general rule of being a username and a password. The username/password ensuring process 
has been discussed above and the code listing thereof is in Appendix A. Meanwhile the host 
250 is acknowledged that the client 200 is about to receive a set of new user credential 
information and expects it therefrom at 268. As soon as the new user credential information is 
arrived, the server 250 updates the user credential information associated with the rendezvous 
at 270. In other words, to pass through the rendezvous to the user account now by other 
devices, the new credential information must be provided. 

With the newly updated user credential information, the user can now log onto the 
rendezvous from any computer in the data network. A PC, which is not shown, connected to 
the data network, is equipped with a familiar HTML-based browser, preferably from Netscape 
Communication Corporation or Microsoft Corporation. As an example, it is assumed that a 
user has just provisioned a rendezvous with a username being "marylee" and the 
corresponding password being "123456". The user now goes to a networked PC that runs a 
Navigator browser from Netscape Communication Corporation and logs onto the rendezvous 
based on the URL of the rendezvous. Figure 6 shows an interactive web page 300 received 
from the server 250 after the PC made the connection to the rendezvous. It is understood to 
those skilled in the art that the page and subsequent pages can be constructed with HTML 
along with CGI script/Java applets, where the process, CGI stands for Common Gateway 
interface, to receive information entered from a user. To update his personalized information 
in his account, the user must provide the newly created username and password required at 
302 and 304. It should be noted that the password entered is generally not echoed at 304 and 
instead indicated with a asterisk corresponding to a letter entered. When the login icon 306 is 
activated, the entered username and password are retrieved and sent, through the network, to 
the server 250 in which the entered username and password are verified; namely the entered 
username and password match those entered and authorized by the user through the client 
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200. The user is then prompted with a second web page 310 shown in Figure 7 in which the 
username is displayed as referenced by 312. To categorize personalized information in the 
account, the web page 310 comprises entries to other specific service pages, such as Personal 
Organizer 314, Bookmarks 316 and Create a Message 318. All these pages are accessible by 
the user to personalize his desired information therein. Figure 8, for example, is a page 326 of 
the Personal Organizer 314 showing a personalized address book 320 that allows the user to 
edit his frequently contacted people's phone numbers and other information. Figure 9 is a 
page of the Bookmarks 316 that allows the user to establish a list of web sites he may 
frequently visit through his cellular client 200, for example, StockTIPS referenced by 322 
allows the user to keep a list of stock symbols there. With the personalized bookmarks, the 
user, when on the go, can quickly enter into the web pages having his list of the stock symbol 
to look up for the prices thereof currently being traded in the stork market without keying in 
any symbols at all. As a convenient feature, the page 330 in Figure 10 allows the user to 
create an email message and be replied to a different address at 332 decided by the user, 
which eliminates the inconvenience of typing a lengthy message through a phone keypad and 
reading a replied message at the small screen in the client 200. 

The contents in the exemplary pages respectively shown in Figures 6, 7, 8, 9 and 10 
composed by HTML are accessible by an HDML browser through a server providing 
communication protocol mapping and markup language translation functions. Similarly 
information or messages entered on the client 200 composed by HDML are equally accessible 
by any computer equipped with an HTML browser through the same server in the data 
network. The duality of the information updating through two different mark-up languages 
provides a useful means for efficiently managing a personal account and solves substantially 
the problems of inconvenient data entry through a less functional keypad. 

The present invention has been described in sufficient detail with a certain degree of 
particularity. It is understood to those skilled in the art that the present disclosure of 
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embodiments has been made by way of example only and that numerous changes in the 
arrangement and combination of parts as well as steps may be resorted without departing from 
the spirit and scope of the invention as claimed. For example, any mobile devices equipped 
with a micro browser, e.g. HDML browser, may be connected, using an adapter, to the 

5 Internet directly without going through the airnet, the emerging Internet-enabled electronic 
appliances are also Internet-connected, all have limited computing powers and keypads but 
are capable of communicating with a server in a data network. The mutual authentication 
between such devices and the server thus becomes less complicated. The mutual 
authentication needs a process of having the client, such as a controller of the electronic 

10 appliance, authenticated by the server and having the server authenticated by the client. The 
process can be carried out in existing encryption mechanisms in HTTPS (an extended version 
of HTTP with built-in security), in which case, the link server could be replaced by a built-in 
capability in the device, or the HTTPS or the transceiver or somewhere in the connection to 
the Internet. The principles of the present invention may still be practiced in such 

15 configuration. Accordingly, the scope of the present invention is defined by the appended 
claims rather than the forgoing description of one embodiment. 
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CLAIMS 



What is claimed is: 

1. A method for provisioning, through a first client, a rendezvous to a user account in a 
server to ensure secure access to the user account by a second client through the 
rendezvous having an address identifier in the server, the method comprising: 

establishing a communication session by the first client with the server using a first 
communication protocol according to the address identifier of the rendezvous; the first 
client having a client identification associated with the user account and running a first 
browser; 

authenticating mutually between the first client and the server so that the 
communication session becomes authenticated between the first client and the server; 
establishing user credential information for the rendezvous by the first client; and 
associating the user credential information with the rendezvous to the user account in 
the server wherein the user account in the server becomes accessible by the second client 
through the rendezvous by supplying the user credential information thereof. 

2, The method as recited in claim 1, wherein the authenticating mutually between the first 
client and the server comprises: 

determining by the server if the first client has the user account created therefor 
and authorized therein according to the client identification of the first client; 

sending a reply response by the server to the first client if the above determining 
the first client by the server succeeds, wherein the reply response comprises server 
information; 

determining, upon receiving the reply response from the server, by the first client 
if the server is recognized by examining the received server information. 
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3. The method as recited in claim 1, wherein the authenticating mutually between the first 
client and the server comprises generating a session credential information comprising a 
mutually accepted cipher and a mutually accepted encrypt key such that all subsequent 
transactions between the first client and the server are encrypted by the encrypt key 
according to the cipher. 

4. The method as recited in claim 3, further comprising: 

establishing a connection by the second client to the rendezvous using a second 
communication protocol according to the address identifier thereof, wherein the second 
client runs a second browser; 

supplying the user credential information to the rendezvous by the second client using 
the second browser; 

verifying the supplied user credential information in the server; and 

allowing access by the second client using the second communication protocol to the 
user account in the server if the supplied user credential information is verified. 

5. A system for secure access over a data network to a user account, through a rendezvous 
identified by an address identifier, in a server, the rendezvous being exclusively 
designated to the user account, the system comprising: 

a server coupled to the data network; 

a first client, remotely located with respect to the server and coupled to the data 
network using a first communication protocol, having a client identification and running a 
first browser; 

a second client, coupled to the data network using a second communication protocol, 
running a second browser; 

a communication protocol mapper for mapping the first communication protocol to the 
second communication protocol and the second communication protocol to the first 
communication protocol, and 
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means for establishing an authenticated communication session between the first client 
and the server through the data network, the authenticated communication session 
establishing means comprising: 

means for recognizing the first client by the server according to the client 
5 identification and 

means for recognizing the server by the first client according to a reply response 
from the server after the first client is recognized by the server. 

6. The system as recited in claim 5, further comprising means, in the first client and through 
the established authenticated communication session, for updating the rendezvous with 

1 0 user credential information. 

7. The system as recited in claim 6, further comprising means for verifying the user 
credential information supplied by the second client using the second browser after the 
second client logs onto the rendezvous according to the address identifier thereof. 

8. The system as recited in claim 7 wherein the first client is a thin computing device and 
15 wherein the first browser is a micro-browser. 

9. The system as recited in claim 7 wherein the first client is a mobile phone; wherein the 
first browser is an Handheld Markup Language browser and wherein the first 
communication protocol is Handheld Device Transport Protocol. 

10. The system as recited in claim 9 wherein the second client is a personal computer coupled 
20 to the data network. 

11. The system as recited in claim 10, wherein the second communication protocol is 
Hypertext Transfer Protocol and wherein the second browser is an Hypertext Markup 
Language browser. 
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12. A method for provisioning, through a first client, a rendezvous to a user account in a 
server to ensure secure access to the user account by a second client through the 
rendezvous having an address identifier in the server, the method comprising: 

initiating a transaction signal by the first client to the server using a first 
5 communication protocol; the first client having a client identification associated with the 

user account and running a first browser, wherein the transaction signal comprises the 
client identification and the address identifier of the rendezvous; 

examining a communication session between the first client and the server, wherein 
the examining session comprises: 
10 creating the communication session between the first client and the server if 

the communication session is not in existence or is not valid; 

conducting mutual authentication between the first client and the server; and 
generating session credential information for the communication session such 
that subsequent transactions are encrypted by the session credential information; 
15 establishing by the first client user credential information for the rendezvous if the 

communication session is valid; and 

associating the user credential information with the rendezvous to the user account in 
the server. 

13. The method as recited in claim 12 further comprising updating the managed information 
20 in the user account in the server by the first client using the first browser. 

14. The method as recited in claim 13, wherein the first browser is a micro-browser. 

15. The method as recited in claim 14. wherein the first browser is an Handheld Device 
Markup Language browser. 
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16. The method as recited in claim 15 wherein the initiating the transaction signal comprises 
hyperlinking the rendezvous using the first communication protocol according to the 
address identifier of the rendezvous. 

17. The method as recited in claim 16 wherein the first browser is Handheld Device Markup 
5 Language browser and wherein the first communication protocol is Handheld Device 

Transfer Protocol. 

18. The method as recited in claim 17, wherein the user credential information comprises a 
username and a password; 

19. The method as recited in claim 12, wherein the transaction signal initiated by the first 
10 client comprises the address identifier of the rendezvous. 

20. The method as recited in claim 19, wherein the mutual authentication conducting between 
the first client and the server comprises the server conducting a client authentication and 
the client conducting a server authentication, wherein the client and the server are 
communicated in the authenticated communication session. 

15 21. The method as recited in claim 12, wherein the transaction signal initiated by the first 
client comprises at least one client message encrypted by a secret encrypt key shared 
between the first client and the server. 

22. The method as recited in claim 21, wherein the mutual authentication conducting between 
the first client and the server comprises: 
20 conducting a first client authentication in the server by decrypting the encrypted client 

message in the transaction signal from the first client; 

conducting a first server authentication in the first client by decrypting an encrypted 
server message in a server response from the server after the first client authentication in 
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the server succeeds, wherein the server response further comprises a session key and a 
client derivative of the client message; 

conducting a second server authentication in the first client by verifying the client 
derivative with respect to the client message; 
5 conducting a second client authentication in the server by decrypting a client response 

from the first client wherein the client response comprises a server derivative of the server 
message; and 

finalizing session credential information comprising a session ID, the session key and 
a mutually agreed cipher such that subsequent transactions between the first client and the 
10 server are encrypted by the session key according to the mutually agreed cipher. 

1 1 23. The method as recited in claim 12 further comprising: 

7; establishing a second communication session between the second client and the server 

U% using a second communication protocol according to the address identifier of the 

rendezvous; 

%y 15 providing the user credential information, by the second client, to the rendezvous; 

verifying the user credential information provided by the second client in the server; 

O and 

y;| accessing the managed information in the user account in the server by the second 

client using a second browser if the user credential information supplied by the second 
20 client is verified. 

24. The method as recited in claim 23, wherein the establishing the communication session 
between the second client and the server comprises creating the communication session 
between the second client and the server if the communication session is not in existence 
or is not valid. 
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25. A system for secure access, through a rendezvous having an address identifier, a user 
account in a server, the rendezvous being exclusively designated to the user account, the 
system comprising: 

a data network comprising an airnet supporting a first communication protocol and 
a landnet supporting a second communication protocol, the landnet coupled to the 
server; 

a first client, remotely located with respect to the server and coupled to the airnet 
using a first communication protocol, having a client identification exclusively 
associated with the rendezvous and running a first browser ; 

a second client coupled to the landnet using a second communication protocol and 
running a second browser; 

means for mapping the first communication protocol to the second communication 
protocol and the second communication protocol to the first communication protocol; 
the first client communicating with the server via the communication protocol means; 

means for creating an authenticated and secure communication session between 
the first client and the server through the data network; the session creating means 
comprising: 

means for requesting the session by the first client to the server if the session is 
not in existence or in not valid; 

means for conducting mutual authentication between the first client and the 
server; and 

means for generating session credential information for the session in creation; 
means, in the first client and through the created session, for updating the 
rendezvous with user credential information by a first browser such that the user 
account is accessible by the second client through the rendezvous with the user 
credential information. 



26. The system as recited in claim 25, further comprising means, in the second client, for 
providing the user credential information to the rendezvous so as to access the user 
account in the server, thereby the second client can update the managed information 
therein using the second browser. 

5 27, The system as recited in claim 26 wherein the first client is a mobile computing device 
and wherein the first browser is a micro-browser. 

28. The system as recited in claim 27, wherein the first client is a cellular telephone and 
wherein the first communication protocol is Handheld Device Transfer Protocol and 
wherein the first browser is Handheld Device Markup Language. 

10 29. The system as recited in claim 27, wherein the first client is a cellular telephone and 
wherein the first communication protocol is Hypertext Transfer Protocol and wherein the 
first browser is Handheld Device Markup Language browser. 

30. The system as recited in claim 25, wherein the conducting mutual authentication means 
comprises: 

15 means for conducting first client authentication in the server; 

means for conducting first server authentication in the first after the first client 
authentication in the server succeeds; 

means for conducting second server authentication in the first client; and 

means for conducting second client authentication in the server after the first and 

20 second server authentication succeed in the first client. 

31. The system as recited in claim 30, further comprising means for generating session 
credential information for the first client and the server; wherein the credential 
information comprises a session ID, a session key and a mutually agreed cipher such that 
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subsequent transactions between the first client and the server are encrypted by the session 
key according to the mutually accepted cipher; 
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Method and System for Self-provisioning a Rendezvous to Ensure 
Secure Access to Information in a Database from Multiple Devices 



Applicants: Andrew L Laursen 
Bruce K. Martin 
Alain S. Rossmann 

File No.: 89710-2 



Abstract 



The present invention has been made in consideration of thin devices efficiently 
communicating ideas and transactions into data networks by using other devices with full 
functional user interface in the networks. According to one aspect of the present invention, the 
thin device exclusively controls the authentication of a rendezvous that is associated with a 
user account in a server. The thin device running a micro-browser provisions the rendezvous 
with a set of credential information in an authenticated and secure communication session so 
that the provisioning process is truly proprietary. To access the user account, the other devices 
equipped with well known browsers must submit the correct credential information to the 
rendezvous for verification in the server. Once admitted, the other devices can update 
managed information in the user account, individually and respectively, thereby the thin 
device is able to conduct desired transactions based on the managed information in the user 
account without the need to key in pertinent information of the transactions. 
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